デブサミ2016レポート「今日の習慣が明日をつくる～よりよい技術者を目指して～」
こんにちは、虎塚です。
Developers Summit 2016でセッション【19-C-3】「今日の習慣が明日をつくる～よりよい技術者を目指して～」を聴講したのでレポートします。佐藤太一さんが講演されました。
セッション概要
発表者が習慣的に行っているエンジニアとしての訓練のうち、明文化できるもの、価値があると思われるものを整理して伝える。このセッションの目標は、「技術者としての習慣を見直すきっかけを提供すること」。自分にマッチするものを見つけて習慣に取りいれ、皆でよい技術者になろう。
よい技術者とは？
このセッションでは、読む力、書く力、捨てる力の3つが高い技術者を「よい技術者」と定義する。
読む力とは
- 仕様を読む力
- 書かれていることを読み取る力だけでなく、仕様に書かれていない暗黙の前提条件や仮定を適切に理解する力を含む
- より少ない時間でたくさんのコードを把握する能力
- 関数やオブジェクトの関係性を把握
- 評価する能力
- 他人が作ったものや過去自分が作ってきたものについて、設計や品質の妥当性を検証する能力
書く力とは
- 仕様に対して妥当なアルゴリズムを実装する基本の能力
- 書いたコードの制約を明らかにすること
- 仕様に書かれていなくて類推した部分
- 使っているプログラミング言語やプラットフォームによる制約
- 書いたコードの最低限の品質をテストによって保証する能力
- なぜ品質を保証するときっぱり言わないかというと、QAは独立した能力と考えるため。しかし、QAがテストを開始できるだけの品質を提供する能力は必要
- 結合テストくらいまではデベロパーの担当範囲と考える。その範囲ですべてのエッジケースを潰せることは想定しない。もちろん、デベロパーがそれをできるに越したことはない。
捨てる力とは
- 現在のコードを作り直す能力
- 人は古いコードを見るとやり直したくなるが、本当にそれができるかは能力に依存する
- 多くの場合、捨ててやり直すことはそれほど簡単ではない
- 価値を持って動いているシステムを簡単に捨てることはできない
- 捨てる訓練が必要
- 現在のコードを厳密に再定義する能力
- レガシーコードは、テストがなかったり仕様書がなかったりと仕様に不明確な部分が多い
- それでもソースコードを読んで現在の仕様を再定義できる能力
- 同じ仕様をさまざまな方法で表現する能力
- 仕様に対する実装は1つではない。パラダイムやアーキテクチャが違うさまざまな実装が提供できるはず
- 日々成長しているなら過去のコードは捨てられるようになる。また、コードを捨てることで成長実感を得る
よい技術者になる方法
結論: 仕様書とコードを大量に読んで、書いて、捨てる。ショートカットはない。
仕様書を読む習慣
標準化された仕様書をごく当たり前のように読む習慣をつけよう。
ISO、IEEE、IETFのRFC、W3C、WHATWG、JavaプログラマならJEP、JCPのJSRなど、自分の業務領域に近い標準化団体をウォッチしよう。
仕様書を読むことの意味
- 標準化された仕様書は、高度な技量のある技術者が集まって議論した成果なので、高度に整理された知見がつまっている。そこから都合のよい箇所だけを拾う
- たとえば、ISOの標準化資料は全部入り。ロケットを飛ばすようなプロジェクトにも適用できる網羅性を持つ。そこから自分のプロジェクトにあわせて引き算する。
- 自分でゼロから作るのは大変だが、ちょっとだけ削除したり変更したりするのは簡単。標準化資料がどこにあるかと、どう読むかを知っていればよい
- 技術の原理原則を理解するため
- エンジニアリングの根幹
- ワークアラウンドする前に仕様を確認する
- 仕様を理解した上で、自分たちの都合のよいようにワークアラウンドするのはよいが、原理原則を理解せずに「とりあえずこれで動くから」とワークアラウンドをするのは最悪
- アプリやミドルが正しく動いているかを検証するため
- 現代的なアプリは、仕様が広く公開されていることを前提としているものを使って実装されている
- 公開されたフェアな仕様に則らない製品を回避する
- (例) 昔のInternet Explorerはインターネットの標準とかけはなれた動作をしていた
どの仕様書を読むか
まずHTMLから
- 巨大な仕様なので、すべて通して読む必要はない。日常でHTMLの要素や属性についてわからないことがあれば、適当に検索する前にW3CやWHATWGの仕様書を確認しよう
- 仕様書特有の言い回しや分かりづらさには慣れるしかない
- とはいえ、動作するものが正義という団体なので、ほかの仕様書とくらべると読むのがそれほどつらくない
RFCなら2119から
RFC2119 (Key words for use in RFCs to Indicate Requirement Levels) では、「MUST」や「SHOULD」などRFCの要求の程度を示す表現について定義している。
ふだん自分で仕様書を書く時にも、要求の程度の表現について意識し、「やるべきこと」と「やることが望ましいこと」を区別して書くことが望ましい。要求の程度についての表現が一貫していると、読みやすい仕様書になる。
RFCの本命はHTTP1.1
- RFC2119の次に、RFC7231 (Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content) を開始点として読んでいく
- （本セッションの会場にいる）多くの人はなんらかの形でWebに関わるシステムの開発をしているはず
- 最先端のHTTP2はHTTP1.1を完全に前提にしているので、まずHTTP1.1から理解する
- RFC7231では、HTTPのステータスコードやheaderの意味を説明している
- たとえば、RESTfulなアプリでどんなステータスコードを返せばよいかよくわからない、という時に読む
- おすすめの読み方
読んでほしいJSR
発表者がJavaエンジニアなので、おすすめのJSRを挙げる。
- Java Transaction API
- Java Servlet 2.4
- すこし古めのServlet仕様。ほかのWebフレームワークでも参考にしているものがおおい
- Java Servlet 3.1
- WebSocketなど最先端の技術にいち早く取り組んだJSR。
論文と仕様書ならIEEE
- IEEE 754-2008 (参照: IEEE 754: Standard for Binary Floating-Point Arithmetic)
- 浮動小数点演算に関する仕様
- たとえば、Javaで浮動小数点の計算をしたら負けというが、なぜ負けなのかがこれを読めばわかる
網羅性が気になったらISO
自分の開発のやり方は正しいのか。作成しているドキュメントに不足はないか。プロジェクトがうまく回っていないが、何が足りないかわからない。プラクティスを取り入れてみたが、多すぎたり少なすぎたり、形骸化したりする……といった悩みに直面したら、ISOの仕様書にあたる。
- 網羅性の高い仕様にあたり、不要なものを削って、よさそうなものだけを拾う
- ISOの仕様書は、内部が細かく分かれていてモジュール性をもっている。一部だけ取り出してプロセスをモデリングしやすい作り
- おすすめのISO仕様書
- ISO 12207: ソフトウェアライフサイクル全般
- ISO 90003: ソフトウェアの品質保証
まとめ: 議論の起点は仕様書であるべきなので、仕様書を読もう。よい技術者は仕様書をよく確認している。
コードを読む習慣
- Githubには成長の機会がある
- 大量のよいコードがある（悪いコードもある）
- 貢献の機会がある
- OSSなら無償でリポジトリを公開できる
- 公開状態で作業するならタダで使わせてくれる
毎日ログインしよう
- 毎日5分Trending repositories on GitHub todayを見よう
- どんな言語が流行り、開発者が注目されているかを見る
- 最初はリポジトリまで見なくてもいい。惰性でトレンドを見る習慣をつけるのが大事
- 言語を絞らずにトレンドに上がるリポジトリを見てみると、誰かが学習成果を公開しているリポジトリが多い
- だれかがムリのないやり方で続けて、上手くいったものを、皆が見にいっていることがわかる
-
Gituhub以外の情報源としては、Techblogがおすすめ
- Voxxed
毎日30分コードを眺めよう
理解しなくていいので、トレンドに上がってくるリポジトリを開発言語で食わず嫌いせずに眺めよう。
コードを眺めるとは
- 絵画的に鑑賞する（CSSのblurがかかっているような状態をイメージ）
- キーワードとそうでないものを色で区別する程度に
- 単語は見ない
- インデントは見る
- (例) コメントがあるとか、ほかのモジュールへの依存性があるとか、ネストが深いが規則性ある、とか
なぜ眺めるのか
- 知らないものへの恐れを減らすため
- 意識しないレベルで見たことがあるものを脳に記録するため
- 将来たくさんコードを読んでいくための準備
- 既視感のあるものは挫折しづらい
- よい処理構造はあまり言語に関係ない
コードを見慣れよう
- モチベーションなしにコードを見られるようになろう
- 呼吸するたびに意識を高めたりはしないよねと
- 気がついたら眺めている状態を目指す
読むべきリポジトリ
- 得意言語で書かれているもの
- リポジトリの説明がわかりやすいもの
- Readmeに目的や価値、ビルド方法、使い方が書いてあるもの
- 半年以内のコミットがあるもの
- CIサービスと連携していて、成功が維持されているもの
- CIがコケている場合、リポジトリが荒れていて、学べるものの量がすくない可能性がある
コードの読みはじめかた
- 依存ライブラリを確認する
- 知らないライブラリがあれば、そちらを優先して読んだほうが、すぐに役立つことが多い
- ビルドする
- ユニットテストを実行する
- エディタやIDEは慣れたものを使う
コードの読み方
- リポジトリ内のすべてのコードを何度も眺める
- 15〜30分区切りでどんどん読む
- 広く浅くさまざまな部分をぼんやり覚えている状態を目指す
- main関数やアプリケーション呼び出し箇所など、外部との境界面から読む
- 仮説と検証を繰り返しながら読むことで、記憶に定着しやすくなる
- 抽象度の高い部分を優先して理解する
- ヘッダファイルやインタフェース、抽象クラスなどのコンストラクトから読む
- むずかしい部分はエディタでブックマークして後回しにする
- コードが荒れている箇所は、git blameすると、書いた人たちの苦労を眺めることができる
- UMLのような絵を使うと分かりやすい
- デバッガを使うと動作をより正確に把握できる。ただし、状況が固定されるかもしれない
まとめ: コードは高速に読もう。毎日読むなら、ほかのことができるように、速く読めたほうがよい。読む速度は改善できる。
コードを書く習慣
- 年をとるとコードを書けなくなる？
- SI系企業では実装工程をおこなう技術者への評価は残念ながら低めであることが多い
- 30代中盤にもなるとリーダーシップを期待される
- 規模のある組織としては、若手が育つこともミドルマネジメントも重要
このような背景もあり、かならずしも仕事でコードを書けるとはかぎらない。そこで、一人砂場プロジェクトをしよう。
一人砂場プロジェクトをしよう
- 一人でコードを書き、学ぶ遊び。自分で全部やる。誰にもまかせない
- 仕事ではないので計画しない、リスクコントロールしない、やりたいときだけやる、飽きたらやめる
- 書いたコードは公開しなくてもいい
- でも公開したほうがよい。恥ずかしいかもしれないが、どうせ誰もまったく見ていないので大丈夫
一人砂場プロジェクトをする意味
- しがらみのない自由を味わうため
- 自分の能力を後で客観的に評価できる。1年前にどうだったかがシビアにわかる
- 価値観を少しずつ変えるため
- 価値の不明瞭なものを評価するため
- (例) オブジェクト指向、関数型ときて、次はどんな新しいパラダイムがくるのか
- 一人砂場プロジェクトでそういったものを試しておくと、仕事で新しいパラダイムに安全に移行できる
一人砂場プロジェクトで何をするか
- よさそうなものを何でも使ってみる
- 言語、ライブラリ、フレームワーク、CIサービス、PaaS
- 今使っている道具を点検する
- もっと便利なエディタはないか、もっと速いビルドツールはないか
何か作りたいけどネタがない人へのおすすめ
- 短縮URLを生成する画面のないサーバ
- postボディにURLつけてリクエストするとレスポンスボディに短縮済みのurlをかえす
- ブログサーバ railsチュートリアル
- ファイルアップローダ
小さい車輪を再発明しよう
- ほかの言語にあるけど得意言語にはないものを実装する
- たとえばxUnitはそのようにして多くの言語に輸出されてきた
- 最近は新しい言語が出るとRSpecモドキがどんどん出る
- (例) taichi/siden: tiny web application framework for Java SE 8 on top of undertow.は、Java8でNodeのExpressモドキを実現しようとした
毎日すこしずつ書こう
- 最初はエディタを起動して新しいプラグイン入れるだけでいい
- 数百行かけたらしめたもの
- 楽しくやろう！
捨てる習慣
どんどんコードを書いてくと、やがて「もうだめだ、捨てよう!!」という最高の瞬間が訪れる。
- 毎日書いていれば、半年くらいで大きなコードベースになる
- そこでやり直せれば大きく成長できる
- はじめから終わりまでを何度も繰り返す
- よい技術者は同じ仕様で何度もコードを書いている
まとめ
よい技術者になるには、仕様書とコードを大量に読んで、書いて、捨てること。無理をせずにやっていきましょう。
おわりに
最初に「明文化できる習慣を紹介する」と述べられていたとおり、小さくはじめる具体的な話がたくさんあり、これなら自分にもできるのではないかと思わせられる、素晴らしいセッションでした。セッションタイトルの「今日の習慣が明日をつくる」はそのとおりで、緊急度は低いけれども大事なことを、つい後回しにしがちですが、むりせず習慣として回していきたいと思いました。
私事ですが、発表者の佐藤さんが数年前に公開された「太一のコードの読み方メモ」を参考に、JVMコードリーディングをしたことがあり、今回はどんなお話が聞けるのだろうと楽しみに参加しました。今回のセッションでは省略された「仕様書を書く習慣」や「他人や自分が書いたものを評価する力」のつけ方についても、いつかどこかで聴けるとうれしいです。
それでは、また。
![[参加レポート] 第26回クラウド女子会 AWS BuilderCardsをプレイしよう #cloudgirl #jawsug](https://devio2024-media.developers.io/image/upload/v1730540918/user-gen-eyecatch/vf89er8xbjntpesixv4u.png)
